Date: Sun, 28 Mar 93 04:30:11 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V93 #80 To: tcp-group-digest TCP-Group Digest Sun, 28 Mar 93 Volume 93 : Issue 80 Today's Topics: Ftpmotd in jnos v108d (2 msgs) G8BPQ with IP Router KA9Q NOS questions... (2 msgs) TCP-Group Digest V93 #79 (2 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Sat, 27 Mar 93 17:43:49 EST From: Steve Urich Subject: Ftpmotd in jnos v108d To: TCP-Group@ucsd.edu Hello, for those of you who are interested I have changed the ftpmotd in jnos ftpserv to conform to internet standards. I have put the motd in my version of net and also in a version of pa0gri. It works with most of the original ka9q ftpcli including net and most nos except the jnos client with has a verbose default problem that somebody changed. I sent my changes to Johan and explained the problem. Its due to the client remaining quiet till a remote command is ordered giving it a V_NORMAL verbose. Then the ftpmotd gets shown when a data port is able to be read verbose. It works normal with net and other versions of nos clients showing the motd at 230 AFTER the login as it should be. I mainly changed the motd routine and added it also to my server because of the way it was sent out at 220 breaking my ka9q net client. Since I don't have a dos box to compile jnos I can't fix the jnos client myself without some debugging since the initial test with wa3dsp Doug has proven to be ok with my client by a slight difference in the jnos client because of its verbose. Since I can't debug and compile jnos because I don't have a dos box I had wa3dsp compile it for me. It worked ok for me but the jnos client was coded differently then the vanilla client code. It looks easy enough to debug if I had a dos machine an compiler. Here are the diffs to the change from 220 to 230 for the motd. 73 - Steve ----Start `diff -c' ftpserv.c v1.08d---- *** ftpserv.old Wed Mar 24 18:20:45 1993 --- ftpserv.new Fri Mar 26 01:26:59 1993 *************** *** 55,62 }; /* Response messages */ ! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n"; ! static char banner1[] = "220 Ready on %s"; static char badcmd[] = "500 Unknown command\n"; static char binwarn[] = "100 Warning: type is ASCII and %s appears to be binary\n"; static char unsupp[] = "500 Unsupported command or option\n"; --- 55,62 ----- }; /* Response messages */ ! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n"; ! static char banner1[] = "230 Ready on %s"; static char badcmd[] = "500 Unknown command\n"; static char binwarn[] = "100 Warning: type is ASCII and %s appears to be binary\n"; static char unsupp[] = "500 Unsupported command or option\n"; *************** *** 173,179 long t; int cnt,i; struct sockaddr_in socket; - FILE *fp; sockmode(s,SOCK_ASCII); memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */ --- 173,178 ----- long t; int cnt,i; struct sockaddr_in socket; sockmode(s,SOCK_ASCII); memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */ *************** *** 197,209 log(s,"open FTP"); usprintf(s,banner,Hostname,Version); - if((fp = fopen(Ftpmotd,"r")) != NULL) { - while(fgets(buf,128,fp)) { - rip(buf); - usprintf(s,"220- %s\n",buf); - } - fclose(fp); - } time(&t); cp = ctime(&t); --- 196,201 ----- log(s,"open FTP"); usprintf(s,banner,Hostname,Version); time(&t); cp = ctime(&t); *************** *** 211,218 if((cp1 = strchr(cp,'\n')) != NULLCHAR) *cp1 = '\0'; #endif - - usprintf(s,banner1,cp); loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){ /* He closed on us */ --- 203,208 ----- if((cp1 = strchr(cp,'\n')) != NULLCHAR) *cp1 = '\0'; #endif loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){ /* He closed on us */ *************** *** 568,574 struct ftpserv *ftp; char *pass; { ! char *path; char *p; int anony = 0; --- 558,564 ----- struct ftpserv *ftp; char *pass; { ! char *path,buf[128],*cp; char *p; long t; FILE *fp; *************** *** 570,575 { char *path; char *p; int anony = 0; path = mallocw(200); --- 560,567 ----- { char *path,buf[128],*cp; char *p; + long t; + FILE *fp; int anony = 0; path = mallocw(200); *************** *** 590,595 if((p = strchr(path,';')) != '\0') *p = '\0'; /* delimit initial cd */ #endif if(!anony){ usprintf(ftp->control,logged); --- 582,598 ----- if((p = strchr(path,';')) != '\0') *p = '\0'; /* delimit initial cd */ #endif + time(&t); + cp = ctime(&t); + usprintf(ftp->control,banner1,cp); + + if((fp = fopen(Ftpmotd,"r")) != NULL) { + while(fgets(buf,sizeof(buf),fp)) { + rip(buf); + usprintf(ftp->control,"230- %s\n",buf); + } + fclose(fp); + } if(!anony){ usprintf(ftp->control,logged); ---End of diff cut here--- -- |Stephen Urich| Internet:steve@zero.com | "Cattle mutilations | |NIC: SU2 | UUCP:uunet!beyonet!steve | are up!" --Sneakers | |ARS: WB3FTP | Packet:WB3FTP@WB3FTP.#EPA.PA.USA.NOAM | ax25<->PBBS<->IPGATE| |Bensalem, PA |Radio:wb3ftp@wb3ftp.ampr.org[44.80.8.44]| TCP/IP-FTP-SMTP-UNIX| ------------------------------ Date: Sat, 27 Mar 93 17:43:49 EST From: Steve Urich Subject: Ftpmotd in jnos v108d To: TCP-Group@ucsd.edu Hello, for those of you who are interested I have changed the ftpmotd in jnos ftpserv to conform to internet standards. I have put the motd in my version of net and also in a version of pa0gri. It works with most of the original ka9q ftpcli including net and most nos except the jnos client with has a verbose default problem that somebody changed. I sent my changes to Johan and explained the problem. Its due to the client remaining quiet till a remote command is ordered giving it a V_NORMAL verbose. Then the ftpmotd gets shown when a data port is able to be read verbose. It works normal with net and other versions of nos clients showing the motd at 230 AFTER the login as it should be. I mainly changed the motd routine and added it also to my server because of the way it was sent out at 220 breaking my ka9q net client. Since I don't have a dos box to compile jnos I can't fix the jnos client myself without some debugging since the initial test with wa3dsp Doug has proven to be ok with my client by a slight difference in the jnos client because of its verbose. Since I can't debug and compile jnos because I don't have a dos box I had wa3dsp compile it for me. It worked ok for me but the jnos client was coded differently then the vanilla client code. It looks easy enough to debug if I had a dos machine an compiler. Here are the diffs to the change from 220 to 230 for the motd. 73 - Steve ----Start `diff -c' ftpserv.c v1.08d---- *** ftpserv.old Wed Mar 24 18:20:45 1993 --- ftpserv.new Fri Mar 26 01:26:59 1993 *************** *** 55,62 }; /* Response messages */ ! static char banner[] = "220- %s, KA9Q-NOS FTP version %s\n"; ! static char banner1[] = "220 Ready on %s"; static char badcmd[] = "500 Unknown command\n"; static char binwarn[] = "100 Warning: type is ASCII and %s appears to be binary\n"; static char unsupp[] = "500 Unsupported command or option\n"; --- 55,62 ----- }; /* Response messages */ ! static char banner[] = "220 %s, KA9Q-NOS FTP version %s\n"; ! static char banner1[] = "230 Ready on %s"; static char badcmd[] = "500 Unknown command\n"; static char binwarn[] = "100 Warning: type is ASCII and %s appears to be binary\n"; static char unsupp[] = "500 Unsupported command or option\n"; *************** *** 173,179 long t; int cnt,i; struct sockaddr_in socket; - FILE *fp; sockmode(s,SOCK_ASCII); memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */ --- 173,178 ----- long t; int cnt,i; struct sockaddr_in socket; sockmode(s,SOCK_ASCII); memset((char *)&ftp,0,sizeof(ftp)); /* Start with clear slate */ *************** *** 197,209 log(s,"open FTP"); usprintf(s,banner,Hostname,Version); - if((fp = fopen(Ftpmotd,"r")) != NULL) { - while(fgets(buf,128,fp)) { - rip(buf); - usprintf(s,"220- %s\n",buf); - } - fclose(fp); - } time(&t); cp = ctime(&t); --- 196,201 ----- log(s,"open FTP"); usprintf(s,banner,Hostname,Version); time(&t); cp = ctime(&t); *************** *** 211,218 if((cp1 = strchr(cp,'\n')) != NULLCHAR) *cp1 = '\0'; #endif - - usprintf(s,banner1,cp); loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){ /* He closed on us */ --- 203,208 ----- if((cp1 = strchr(cp,'\n')) != NULLCHAR) *cp1 = '\0'; #endif loop: if((cnt = recvline(s,buf,sizeof(buf))) == -1){ /* He closed on us */ *************** *** 568,574 struct ftpserv *ftp; char *pass; { ! char *path; char *p; int anony = 0; --- 558,564 ----- struct ftpserv *ftp; char *pass; { ! char *path,buf[128],*cp; char *p; long t; FILE *fp; *************** *** 570,575 { char *path; char *p; int anony = 0; path = mallocw(200); --- 560,567 ----- { char *path,buf[128],*cp; char *p; + long t; + FILE *fp; int anony = 0; path = mallocw(200); *************** *** 590,595 if((p = strchr(path,';')) != '\0') *p = '\0'; /* delimit initial cd */ #endif if(!anony){ usprintf(ftp->control,logged); --- 582,598 ----- if((p = strchr(path,';')) != '\0') *p = '\0'; /* delimit initial cd */ #endif + time(&t); + cp = ctime(&t); + usprintf(ftp->control,banner1,cp); + + if((fp = fopen(Ftpmotd,"r")) != NULL) { + while(fgets(buf,sizeof(buf),fp)) { + rip(buf); + usprintf(ftp->control,"230- %s\n",buf); + } + fclose(fp); + } if(!anony){ usprintf(ftp->control,logged); ---End of diff cut here--- -- |Stephen Urich| Internet:steve@zero.com | "Cattle mutilations | |NIC: SU2 | UUCP:uunet!beyonet!steve | are up!" --Sneakers | |ARS: WB3FTP | Packet:WB3FTP@WB3FTP.#EPA.PA.USA.NOAM | ax25<->PBBS<->IPGATE| |Bensalem, PA |Radio:wb3ftp@wb3ftp.ampr.org[44.80.8.44]| TCP/IP-FTP-SMTP-UNIX| ------------------------------ Date: Sun, 28 Mar 93 09:00:50 GMT From: g4klx@g4klx.demon.co.uk (Jonathan Naylor) Subject: G8BPQ with IP Router To: TCP-Group@ucsd.edu Hi All I put BPQ406E.ZIP into the wrong incoming directory. It is now in /hamradio/packet/tcpip/incoming. Sorry Jonathan ------------------------------ Date: Sat, 27 Mar 1993 11:41:17 -0600 (CST) From: gerry@cs.tamu.edu (Gerald J Creager) Subject: KA9Q NOS questions... To: tcp-group@ucsd.edu I recently shipped this to the group, but I've seen neither the question, nor any responses, so I guess it went to a bit bucket in the sky... Let's try again. I recently downloaded Phil's latest from ucsd.edu. I tried to bring it up initially with an autoexec.nos configured for jnos 107b. With the exception of the attach asy statement, I have changed nothing, but I'm seeing some interesting anomolies and NEED some help. 1. Hardware config: '386DX/'387, 4 Mb memory, 130 Mb hard disk, 3 Mb free on NOS logical drive, 6 Mb free on a separate logical drive for /temp. 2. Software Config: QEMM/386, ansi.sys, the world loaded high, 633k available. 3. TNC config: PacComm Tiny-2 with "node" (higher speed) parts, port speed 9600 baud, radio speed 1200 baud, ROM rev. 1.1.6b (PacComm) 4. Recent history: Works "fine" with jnos, older karncode (tm) and g1emmCode (tm). Worked fine at higher radio rates with DataEngine testing last year. 5. Symptoms: A. When I issue *ANY* sort of transmission, with trace turned on, I see an ax.25 "bad header" message in trace. B. Occassionally, say, <10% of the time, I see what looks to the code (appparently) like a good ax.25 packet but is gibberish. C. Other systems see the packets I'm pumping out, and they look normal to them. A connect request using either native ax.25 or tcp/ip results in the other system thinking it can really talk to me, but I cannot make sense of the replys. I have used both the ax25ui and ax25i constructs in the attaach asy command line, with similar results. Since I haven't pulled down the source yet, I have no "documentation" to work with... I need more disk space, and I'm working oin that issue. Anyone got thoughts? I was wondering if KISS wasn't compiled into the code, possibly... If that's the case, I guess I need to learn something about RCS and grab a copy of Borland C++ 3.x... Thanks, Gerry n5jxs gerry@cs.tamu.edu ------------------------------ Date: Sat, 27 Mar 93 17:01:07 EST From: Mike Gallaher Subject: KA9Q NOS questions... To: gerry@cs.tamu.edu (Gerald J Creager) Try using "kissui" or "kissi" instead of "ax25ui"/"ax25i". If you use ax25 encapsulation, it just sends raw ax25 packets to the serial port, assuming that whatever hears them will transmit them literally (like an 8530 card). If you use kiss encapsulation, it prepends a kiss "data follows" byte to the ax25 packet; this is what the TNC expects, to distinguish data from parameter-setting commands, for instance. At least, that's what I've been able to glean from looking at the source, and playing with it for a few minutes. I haven't seen any documentation either. mg ------------------------------ Date: Sat, 27 Mar 93 15:05:15 EST From: Postmaster@alis3.daytonoh.ncr.com Subject: TCP-Group Digest V93 #79 To: tcp-group@ucsd.edu Returned Mail: Could not find any To: or Cc: recipients. *** Returned Mail Message Follows: *** ------------------------------ Date: Sat, 27 Mar 93 04:30:06 PST From: Advanced Amateur Radio Networking Group Subject: TCP-Group Digest V93 #79 To: tcp-group-digest@ucsd.edu TCP-Group Digest Sat, 27 Mar 93 Volume 93 : Issue 79 Today's Topics: 3COM Sniffer Anyone seen this problem before ? (2 msgs) any System V release 3 ports of NOS/NET (KA9q)/slip AX25 and Linux (2 msgs) LAPB bugs Latest BPQ with IP Router TCP-Group Digest V93 #78 (2 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 26 Mar 93 11:28:05 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: 3COM Sniffer To: tcp-group@ucsd.edu I put the file eprobe.zip in the ucsd.edu incoming. It is a PUBLIC DOMAIN ethernet monitor program from 3COM for any of there ethernet board products. It is a nifty way to monitor ethernet traffic on a PC. It has filtering modes and detailed viewing. I thought this might be of interest to the ampr group. If it is not appropriate to have it on here then take it off. Doug ------------------------------ Date: Fri, 26 Mar 93 10:10:09 CST From: andyw@aspen.cray.com (Andy Warner) Subject: Anyone seen this problem before ? To: tcp-group@ucsd.edu (TCP Group) Has anyone seen NOS behave in the following way ? An interface is set up to work in datagram mode, but sometimes NOS decides to start talking in VC mode (to just one or two stations, not everyone on that interface). If the remote station in question has jumpstart on, there's a timewasting round of "Huh?", "Huh?", "Huh?".... until one or other gets bored and drops the ax25 connection. Things I know as facts :- 1. I'm running a very recent version of KA9Q (not JNOS, PA0GRI etc), with some local mods, they might be the culprit, but I thought I'd ask. 2. This has been going on for a while now, so the problem existed with earlier NOS versions I used (PA0GRI based, I believe). 3. It is definately my station that initiates the VC mode, (I send the SABM). Observations that may or may not be true :- 1. I run a name server on my ethernet, and accesses by other stations to the nameserver seem to cause the problem to occur most readily. From the traces I have noticed that sometimes I will get an "ICMP code port unreachable" when I issue a DNS reply, could this be that NOS got bored waiting for my answer, and closed the port ? 2. I've never seen this happen to a TCP connection, only to UDP traffic. If this sounds familiar to anyone, or if you've got any ideas, send mail & I'll summarise. I hope to dive into the code this weekend... -- andyw. N0REN/G1XRL andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Fri, 26 Mar 1993 12:31:34 -0600 (CST) From: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals) Subject: Anyone seen this problem before ? To: tcp-group@ucsd.edu (tcp/ip networking group) > >Has anyone seen NOS behave in the following way ? > >An interface is set up to work in datagram mode, but sometimes >NOS decides to start talking in VC mode (to just one or two Andy, One thing that would cause this is for someone to send a datagram with the "reliability" flag set (0x04) in the IP TOS field. JNOS will send such datagrams in VC mode, regardless of the default "ax25 mode" setting. ------------------------------ Date: Fri, 26 Mar 93 16:34:58 CST From: "Erach A. Irani" Subject: any System V release 3 ports of NOS/NET (KA9q)/slip To: tcp-group@ucsd.edu --- If this is a repeat, please excuse me. I still cannot locate a working implementation, and that seems highly unlikely to me --- Hi, I read that you have agreed to help out by being the coordinator for the UNIX ports. have you heard of a sys 5 release 3 port of nos/net ka9q slip WHICH can allow me to login to the originating machine and do UNIX'ish work (rather than talk alone). A limited number of logins is all I need. Thanks, erach ------------------------------ Date: Fri, 26 Mar 93 08:22:10 CST From: Brian K. Teravskis Subject: AX25 and Linux To: tcp-group@ucsd.edu Is anyone working on getting AX25 incorporated into the Linux kernel or is KA9Q the only way to go for now?? Thanks.. Brian ------------------------------------------------------------------------------ Brian K. Teravskis | Internet: brian@smedley.telex.mn.org Telex Communications, Inc | brian@hercules.vware.mn.org Bloomington, MN 55420 | AMPRNET: brian@hercules.wd0efl.tcman.ampr.org ------------------------------------------------------------------------------ ------------------------------ Date: Fri, 26 Mar 1993 09:50:10 -0800 (PST) From: Bruce Perens Subject: AX25 and Linux To: "Brian K. Teravskis" Right now, you must run a KA9Q variant such as WAMPES under Linux, because the various people who have been hacking in AX.25 drivers aren't ready to release them. We're waiting for the SLIP modifications to the kernel (mostly STREAMS support) to stabilize, as we want to use some of that to support AX.25. Also, the Linux TCP/IP implementation is still being debugged - the original developer has left the effort in a huff due to too much criticism, and others are now posting about one bug-fix a day. I find that running KA9Q under Linux is much more comfortable than running KA9Q on DOS, simply because of the multi-tasking - I can do something else with the computer while KA9Q is running, and if KA9Q dies it doesn't crash the system. It is going to be nice when we can abandon the monolithic structure of NOS, and break the system into separate processes. I find it much easier to modify and debug that way. Bruce Perens KD6OTD On Fri, 26 Mar 1993, Brian K. Teravskis wrote: > Is anyone working on getting AX25 incorporated > into the Linux kernel or is KA9Q the only way > to go for now?? > > Thanks.. > > Brian > > ------------------------------------------------------------------------------ > Brian K. Teravskis | Internet: brian@smedley.telex.mn.org > Telex Communications, Inc | brian@hercules.vware.mn.org > Bloomington, MN 55420 | AMPRNET: brian@hercules.wd0efl.tcman.ampr.org > ------------------------------------------------------------------------------ > > ------------------------------ Date: Fri, 26 Mar 93 14:29:55 PST From: psm%helios.nosc.mil@nosc.mil (Scot McIntosh) Subject: LAPB bugs To: tcp-group@ucsd.edu Following are some bugs and deficiencies that I've found in the LAPB code, which a couple of group members have requested that I post. Excuse the extra-wide format. Hope it doesn't make this unreadable for some. ------------------------------ Date: Fri, 26 Mar 93 19:04:03 GMT From: g4klx@g4klx.demon.co.uk (Jonathan Naylor) Subject: Latest BPQ with IP Router To: TCP-Group@ucsd.edu On incoming as ucsd.edu is the latest version of G8BPQs switch software, BPQ406E.ZIP. In it is included the first release of his IP router software that operates as an application above the switch. It has been in beta testing for quite a while in our local packet area with good results. John has added a protocol for auto routing between his switches. Could somebody move it from incoming to the g8bpq directory please. John G8BPQ can now be reached at g8bpq@g4klx.demon.co.uk 73's Jonathan ------------------------------ Date: Fri, 26 Mar 93 11:02:08 EST From: Postmaster@alis3.daytonoh.ncr.com Subject: TCP-Group Digest V93 #78 To: tcp-group@ucsd.edu Returned Mail: Could not find any To: or Cc: recipients. *** Returned Mail Message Follows: *** ------------------------------ Date: Fri, 26 Mar 93 04:30:11 PST From: Advanced Amateur Radio Networking Group Subject: TCP-Group Digest V93 #78 To: tcp-group-digest@ucsd.edu TCP-Group Digest Fri, 26 Mar 93 Volume 93 : Issue 78 Today's Topics: New nos version PA0GRI Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 26 Mar 93 10:08:02 MET From: gvdg@tophat.cdh.cdc.com Subject: New nos version PA0GRI To: tcp-group@ucsd.edu Hello All, Just before going i loaded my latest work on NOS onto ucsd.edu Main work lately was on tcp and ip access code. The c command help display now correctly displays the possible commands for the various compile options of mailbox.c Now i am all set to get "lost" in the big lands and have a good time. >>For all who wrote me a message: I took all notes with me and use them as time and place comes by. Freq for simplex is 145.520 (i forgot the 30kc channel space.) Thanks all those responded , to nummerous to get back to individualy (sorry). Please have funn, i will. Regards, Gerard. -- Internet: gvdg@cdc.com | Gerard J van der Grinten UUCP: gvdgpc!gvdg | Control Data Bv. Telephone: 0(+31)-15-153123 | Olaf Palmestraat 20 | 2616 LS DELFT Netherlands ------------------------------ End of TCP-Group Digest V93 #78 ****************************** ------------------------------ Date: (null) From: (null) Start File Line Function Description lapb.c 168 lapb_input The following code fragment is part of the processing for the LAPB_CONNECTED state. 'control' contains the complete control field from an incoming frame, which, in the case of an RNR, has an N(R) field. Therefore, the control == RNR test fails when the N(R) field of the RNR contains nonzero. Change 'control' to 'type' to fix this. case RR: case RNR: axp->flags.remotebusy = (control == RNR) ? YES : NO; if(poll) enq_resp(axp); ackours(axp,nr); break; lapb.c 371 ackours The ackours() function returns a -1 value to cause a FRMR if an acknowledgement is received for an unsent frame. None of the routines calling ackours pays any attention to the return value. Suggest modifying ackours to send the FRMR itself: static int ackours(axp,n) struct ax25_cb *axp; int16 n; { struct mbuf *bp; int acked = 0; /* Count of frames acked by this ACK */ int16 oldest; /* Seq number of oldest unacked I-frame */ int32 rtt,abserr; /* Free up acknowledged frames by purging frames from the I-frame * transmit queue. Start at the remote end's last reported V(r) * and keep going until we reach the new sequence number. * If we try to free a null pointer, * then we have a frame reject condition. */ oldest = (axp->vs - axp->unack) & MMASK; while(axp->unack != 0 && oldest != n){ >> if((bp = dequeue(&axp->txq)) == NULLBUF){ >> /* Acking unsent frame */ >> sendfrmr(axp, axp->control, LAPB_RESPONSE, axp->pf, Z); >> return -1; } Remainder of routine is same. The arguments to sendfrmr are the offending packet's control and pf fields, an indication that this is a response, and the reason for the FRMR. Note: have to add 'control' and 'pf' fields to struct ax25_cb and fill them with the control and pf fields of the offending incoming frame. Also, the X.25 standard specifies that after sending an FRMR, the DCE enters into a frame rejection condition and waits for a SABM, DISC, or DM from the DTE (this is an abbreviated description of what the standard really says). Suggest adding the LAPB_REJECT state and the processing for it in the lapb_input function, and have the sendfrmr function invoke the LAPB_REJECT state. Also suggest adding sendfrmr(axp, axp->control, LAPB_RESPONSE, axp->pf, W); for the cases where an incoming frame has a control field containing an unknown type. lapb.c various lapb_input The code decides whether the local station is busy by the enq_resp following means: if(len_p(axp->rxq) >= axp->window){ /* Too bad he didn't listen to us; he'll * have to resend the frame later. This * drastic action is necessary to avoid * memory deadlock. */ sendctl(axp,LAPB_RESPONSE,RNR | pf); _or_ tmp = len_p(axp->rxq) >= axp->window ? RNR : RR; The len_p routine only determines the length of the packet at the front of the receive queue. If multiple receive packets are queued, they aren't taken into account in calculating whether the window has been exceeded. lapbtime.c 95 tx_enq The following code fragment is from the tx_enq routine: if(axp->txq != NULLBUF && (len_p(axp->txq) < axp->pthresh || axp->proto == V1)){ /* Retransmit oldest unacked I-frame */ dup_p(&bp,axp->txq,0,len_p(axp->txq)); ctl = PF | I | (((axp->vs - axp->unack) & MMASK) << 1) | (axp->vr << 5); sendframe(axp,LAPB_COMMAND,ctl,bp); } else { ctl = len_p(axp->rxq) >= axp->window ? RNR|PF : RR|PF; sendctl(axp,LAPB_COMMAND,ctl); } A condition can arise wherein a transmit packet has been put on axp->txq, but transmission not initiated because lapb_output() found that axp->flags.remotebusy indicated that the remote station is busy. In this case, if tx_enq() is called by recover() or pollthem(), txq will be non-null, and the I frame could be transmitted. This is incorrect behavior when the remote is busy. If by chance the remote has become unbusy between the time of the lapb_output() failure and the call to tx_enq(), the tx_enq() transmission of the I frame doesn't increment axp->vs, and axp->unack is zero, so an acknowledgement by the remote will not be processed properly by ackours(); ------------------------------ End of TCP-Group Digest V93 #79 ****************************** ------------------------------ End of TCP-Group Digest V93 #80 ****************************** ******************************